Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 1/csmp-v1-147.txt

Text File | 1992-12-31 | 37KB | 1,069 lines

C.S.M.P. Digest             Tue, 21 Jul 92       Volume 1 : Issue 147

Today's Topics:

    Offscreen pixMaps/GrafPorts/gWorlds
    PICT file to PICT resource?
    68040 Cache, 32-bit addressing, & Pascal...
    Bug in PCloseSkt() ???
    How to find the "blessed folder"?
    Yucky "QuickTime Pict" thing in my dialog
    to Null terminated [SUMMARY] and thanks
    How does PrintMonitor do it?



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Bathsheba Grossman)
Subject: Offscreen pixMaps/GrafPorts/gWorlds
Date: 17 Jun 92 05:51:43 GMT
Organization: Extended Bulletin Board Service

Hello world.
I'm perusing the Tech Notes for the first time, having been a macProg for 2
years (at least, that's how long I've been taking money for it), and I just
read  #120, Principia Off-Screen Graphics Environments and panicked.

Do I really have to allocate a new graphics device every time I want
to draw in an offscreen bitmap?  Even if I'm only going to dump it to the
screen in a few ticks?  IM VI 21.5 says not, but the note seems pretty hard-line
about it.  So far I've been doing ok without a gDev or gWorld.

Do I care about the difference between indexed and direct color models?
If so, what do I have to do to remain compatible (at least, with the128K ROM
under System 6.0.5 and up)?  I would also like to be able to run under the
8.24 video card, though I don't have one to test on.

Other questions on my mind: Is the 3K limit on CopyBits() still in force?
And, is there anything I can do to make it go faster, other than seeing
that the offscreen port's width is a multiple of 4.

Thanks a lot - thousands (well, dozens, anyway) of users will appreciate it.
I can be emailed, or if this is of any interest, I'll see it if posted.

- -Sheba
[e-mail]
- --
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 17 Jun 92 10:50:09 GMT
Organization: The World Public Access UNIX, Brookline, MA

OK, don't worry!

You don't need a Graphics Device for a BitMap, only a PixMap. Even then,
you don't _need_ it but it does make for a more elegant solution to dealing
with color tables, etc. Unless, of course, you just use the GWorld calls,
then it's all done for you! Now, if GWorlds only worked on non-color quickdraw
machines, we would be _All Set_...Apple?

As far as CopyBits() 3K limit. That limitation was taken out the day after
it was written about in whatever tech note it's in. ;) Well, not really,
but I've CopyBit's a 13in 256 color display, probably a _little_ more than
3K wouldn't you say?


- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP
- -- asm.comm.networks.cool tunes...

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 17 Jun 1992 14:54:08 GMT

[e-mail] (Bathsheba Grossman) writes:
>I just
>read  #120, Principia Off-Screen Graphics Environments and panicked.
>
>Do I really have to allocate a new graphics device every time I want
>to draw in an offscreen bitmap?  Even if I'm only going to dump it to the
>screen in a few ticks?

No.  Here's (part of) the scoop.  A GDevice keeps track of the "color
environment" you're drawing into.  For example, when CopyBits needs to
know what its destination PixMap's color table is, it ignores the
pmTable field of the PixMap and uses the gdPMap field of the current
GDevice instead.

A "color environment," near as I can figure, is (1) an indication of
whether pixels are indexed or direct, (2) a pixel depth, (3) a color
table, if necessary, and (4) an inverse table, if necessary.  A GDevice
stores a color environment.

If your off-screen pixmaps will all be at the same pixel depth, then
"color environment" equals "color table," for all practical purposes.

If your off-screen pixmaps will all be using the same color table, then
they can share a color environment.

And, if your off-screen color table will always be the same as a
screen's GDevice, then you can borrow its color environment for your
off-screen drawing.  Just SetGDevice() to that screen before your calls,
and be sure to set it back where you found it.  Note that you don't need
to do this, and should _not_ do this, for on-screen drawing, because
QuickDraw will always take care of on-screen color environments for you.

>Do I care about the difference between indexed and direct color models?

I don't know;  do you?  :-)  If you always use CopyBits to put an image
on the screen, then you don't have to worry about whether the _screen_
is indexed or direct.  Is that what you were asking?

>Other questions on my mind: Is the 3K limit on CopyBits() still in force?

Nope.  CopyBits will allocate heap space, if it has to, to do the copy.

>And, is there anything I can do to make it go faster, other than seeing
>that the offscreen port's width is a multiple of 4.

There's lots and lots you can do.  Longword-alignment is just the
beginning.  See TN277, "Of Time and Space and _CopyBits."

My sources are IM, TN120, and "Graphical Truffles:  Multiple Screens
Revealed," an article in the May 1992 develop which, at three pages, has
the highest usefulness-per-word ratio of anything I've read.  If I got
anything wrong, _please_ correct me!
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 In Pascal, don't nest procedures to be passed by procedure pointer.

+++++++++++++++++++++++++++

From: [e-mail] (Chris Hubbard)
Date: 17 Jun 92 22:54:32 GMT
Organization: STRL, Tektronix Inc, USA

Hello.

This is some very nice discussion.  But, My question is slightly different.

I don't need the overhead of Color QuickDraw.  I want to simulate a
Scope display, and I want to use the 8 colors provided in Classic QuickDraw:
Black, White, Red, Green, Blue, Cyan, Yellow, and Magenta.  That is all
I need.  Can GWorlds use BitMaps and GrafPorts instead of PixMaps and
CGrafPorts?

Chris
- --
Chris Hubbard                [e-mail]
Tektronix, Inc                [e-mail]
Computer Research Lab        [phone]
Beaverton, OR 97077

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Thu, 18 Jun 1992 00:37:11 GMT

In article <[e-mail]> [e-mail] writes:

>Can GWorlds use BitMaps and GrafPorts instead of PixMaps and
>CGrafPorts?
>

GWorlds use PixMaps. Period. You can just use a BitMap if you are going to
only use the "classic" colors. It will work fine.



- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP
- -- asm.comm.networks.cool tunes...

+++++++++++++++++++++++++++

From: [e-mail] (Nicholas Jackiw)
Organization: Whole Earth 'Lectronic Link
Date: Thu, 18 Jun 1992 16:16:26 GMT

In article <[e-mail]> [e-mail] (Joe Zobkiw) writes:
>In article <[e-mail]> [e-mail] writes:
>
>>Can GWorlds use BitMaps and GrafPorts instead of PixMaps and
>>CGrafPorts?
>
>GWorlds use PixMaps. Period. You can just use a BitMap if you are going to
>only use the "classic" colors. It will work fine.

I disagree.  "Bitmap" implies one bit per pixel, and hence no room for
color information (classic or CQD).  When you use a classic QD GrafPort
that sits on a screen with depth>1, the grafPort's portBits points to
the screen, which _Color_ Quickdraw recognizes as a pixmap.  Here, drawing
with classic colors works, precisely because the buffer (the screen pixmap)
has sufficient depth to store color information, even though to the
program's eye, it appears as a bitmap.  When you draw to an offscreen
bitmap, however, there is no buffer of greater depth, and your one-bit/
pixel limitation will guarantee that your image is only two color.  (The
two colors, zero and one, are determined at the moment you CopyBits to
a deep screen by the present ForeColor and BackColor.)

If you intend any offscreen manipulation of color, use Color Quickdraw.


- --
                              --- * ---
Nick Jackiw                  [e-mail]   | [e-mail]
Key Curriculum Press, Inc.   Applelink:KEY.EDUSOFT | [phone]
                              --- * ---

+++++++++++++++++++++++++++

From: [e-mail]
Date: 18 Jun 92 00:54:52 EST
Organization: Wright State University

In article <[e-mail]>, [e-mail] (Joe Zobkiw) writes:
> Unless, of course, you just use the GWorld calls, then
> it's all done for you! Now, if GWorlds only worked on non-color quickdraw
> machines, we would be _All Set_...Apple?

Having inquired about this before, I have to say that the GWorld stuff
works well under System 7 on non-CQD machines provided you call
GetGWorldPixMap instead of accessing the portPixMap directly.

What _doesn't_ work is GetForeColor. On a 4 MB Mac+, System 7.0
(tuneup 1.1.1), MacsBug 6.2.2, THINK Pascal 4.0.1, the following code
is illustrative:

program GFCTest;
  var
    c: RGBColor;
    i, j, k, l: Integer;
begin
  i := 1;
  j := 2;
  k := 3;
  l := 4;
  WriteLn(i, j, k, l);
  GetForeColor(c);
  WriteLn(i, j, k, l)
end.

It produces two lines of output

     1     2     3     4
- -32768  4528     6     4

Ooops:-) The variable c is filled in with the correct forecolor
(0,0,0), but the following six bytes get stepped on. This is now known
as bug #100928.

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
| "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
o----------------------------------------------------------------------------o

+++++++++++++++++++++++++++

From: [e-mail] (Josh Adams)
Date: 19 Jun 92 17:11:51 GMT
Organization: Extended Bulletin Board Service

I think that with old Quickdraw, bitMaps etc, you can do the basic 8 colors

You shouldn't need to have to use CQD to get those 8. I used old QD and
got those 8, but I wasn't using offscreen bitmaps, if that has impact.

Josh


- --
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80

---------------------------

From: [e-mail] (Lester Ward)
Subject: PICT file to PICT resource?
Date: 17 Jun 92 18:36:32 GMT

How different are PICT files from PICT resources?  I'm trying to grab a PICT
file, and dump a PICT resource copy of it into a hyperCard stack.  Any
suggestions?  I really don't know exactly where to begin.

Thanks in advance.

Les

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 17 Jun 1992 20:15:06 GMT

In article <ward1.708806192@husc8> [e-mail] (Lester Ward) writes:
>How different are PICT files from PICT resources?  I'm trying to grab a PICT
>file, and dump a PICT resource copy of it into a hyperCard stack.  Any
>suggestions?  I really don't know exactly where to begin.
>

The _only_ difference between a PICT file and a PICT resource is that the
 _file_ has a 512 byte header attached that can be used for whatever the
application that created it would like to use it for (ie: comments, version
information, copyright information, etc.)

Open the PICT file, read it in (starting after the 512 byte header) then
you can call AddResource on the data you have left (the PICT itself).



- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP
- -- asm.comm.networks.cool tunes...

+++++++++++++++++++++++++++

From: Steve Kohlmeyer
Date: 17 Jun 92 21:27:01 GMT
Organization: University of Minnesota

In article <ward1.708806192@husc8> [e-mail] (Lester Ward)
writes:
>How different are PICT files from PICT resources?  I'm trying to grab a PICT
>file, and dump a PICT resource copy of it into a hyperCard stack.  Any
>suggestions?  I really don't know exactly where to begin.
>
>Thanks in advance.
>
>Les
>
If you only have a couple of images to move you can do the following:
    1)  use a graphics program to load the PICT files and
        export them to PICT rsrc.
    2) use ResEdit to copy the PICT rsrc into your HyperCard stack.

Steve K.

+++++++++++++++++++++++++++

From: [e-mail] (Eric J. Baumgartner)
Date: 18 Jun 92 14:09:27 GMT
Organization: Dartmouth College, Hanover, NH

In article <ward1.708806192@husc8>
[e-mail] (Lester Ward) writes:

> How different are PICT files from PICT resources?  I'm trying to grab a PICT
> file, and dump a PICT resource copy of it into a hyperCard stack.  Any
> suggestions?  I really don't know exactly where to begin.

Dartmouth XCMDs has an XCMD called PICTFiletoRes that does this. I
think it's available at sumex.

Eric Baumgartner                   *  [e-mail]
Interactive Media Lab              *  - When in danger or in doubt,
Dartmouth Medical School           *      run in circles, scream and
shout.

+++++++++++++++++++++++++++

From: [e-mail] (Ross Brown)
Organization: Bell-Northern Research
Date: Thu, 18 Jun 92 13:50:32 GMT

In article <ward1.708806192@husc8> [e-mail] (Lester Ward)
writes:
>How different are PICT files from PICT resources?  I'm trying to grab a PICT
>file, and dump a PICT resource copy of it into a hyperCard stack.  Any
>suggestions?  I really don't know exactly where to begin.

Here's a simple MPW script called "DerezPict" which does exactly what you want.
 I forget where I picked this up.  I hope the special Mac characters survive
the trip through your news server.  If not, there's a couple of "option-d"s on
line 19, and a "section mark" (option-6) on line 24.

- ------------ cut here ------------

#  DerezPict
#  Copyright Apple Computer, Inc. 1987,1988
#
#  This script reads a PICT file (where the pict
#  info is stored after the 512th byte in the
#  data fork, and derez'es it into a pict resource,
#  writing to standard output.
#
#  Note: this script doesn't handle any errors
#        that might unexpectantly occur
#
#  Tom Taylor
#  Tuesday, December 1, 1987 1:12:02 PM

if {#} != 1
    echo syntax is: {0} pictFileName
    exit 1
end
echo "read 'PICT' (1)  "{1} ";" | rez    # read the pict file's data fork and
                                        # save it as a PICT resource in rez.out
derez rez.out > DerezPict.tmp            # turn the PICT resource into a hex dump
target DerezPict.tmp                    # open the temporary hex dump file
find 2                                    # move to the first line of the hex dump
clear  :!31                                # clear the 512 header bytes
rez DerezPict.tmp                        # recompile the PICT resource
close -n DerezPict.tmp                    # toss the temporary hex dump file
derez rez.out pict.r                    # finally derez the PICT using the
                                        # template found in pict.r
delete DerezPict.tmp rez.out            # throw away our temporary files

- ------------ cut here ------------

W. Ross Brown                 | from Brown's Dictionary of Psychic Kinematics:
Advisor, Telemanagement Svcs. |                          ex-hil'a-ra'tion (n.)
Bell-Northern Research Ltd.   |                The rate of change of felicity.
Ottawa, Ontario, Canada       | ----------------------------------------------
[e-mail]                   |      Any opinion expressed is mine, not BNR's.


+++++++++++++++++++++++++++

From: [e-mail] (Michael Peterson)
Date: 19 Jun 92 17:32:29 GMT
Organization: University of Southern California, Los Angeles, CA


The file and resource are almost excatly the same. Start reading from the pict
file at position 512 and create a new resource from the handle from the file.

If you need more help I can send you the source for an XCMD next week.


                    Michael L. Peterson
                    [e-mail]
                    USC - UCS - CST

---------------------------

From: [e-mail] (Roby Sherman)
Subject: 68040 Cache, 32-bit addressing, & Pascal...
Date: 17 Jun 1992 20:06:06 -0400
Organization: The Tao of Programming

Hi. A couple of questions / requests

1> I want to declare a pascal procedure that would enable and disable
the 68040 cache. Could someone provide the inline values of the op codes
to enabale and disable the cahce?

2> When you enable or disable the 32-bit addressing in the Memory
Control-Panel, what is being modified? A resource in the system? Boot
Blocks? PRAM??? How can *I* modify this setting without using the memory
CP?


Please leave e-mail with code / responses / etc. and I will post a
summary.



            thanks in advance...


                --Roby
- --
[e-mail]                    Roby Sherman

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 18 Jun 92 17:24:14 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Roby Sherman) writes:
> 1> I want to declare a pascal procedure that would enable and disable
> the 68040 cache. Could someone provide the inline values of the op codes
> to enabale and disable the cahce?

    Procedure DisableInstructionCache;

        CODE
            $7000,            (* moveq.l #0, d0 *)
        $2040,            (* move.l d0, a0 *)
        $A198;            (* _HWPriv *)

    Procedure EnableInstructionCache;

        Inline
        $7000,            (* moveq.l #0, d0 *)
        $307C, $0001,        (* move.w #1, a0 *)
        $A198;            (* _HWPriv *)

    Procedure DisableDataCache;

        Inline
        $7002,            (* moveq.l #2, d0 *)
        $91C8,            (* sub.l a0, a0 *)
        $A198;            (* _HWPriv *)

    Procedure EnableDataCache;

        Inline
            $7002,            (* moveq.l #2, d0 *)
            $2040,            (* move.l d0, a0 *)
            $A198;            (* _HWPriv *)

> 2> When you enable or disable the 32-bit addressing in the Memory
> Control-Panel, what is being modified? A resource in the system? Boot
> Blocks? PRAM??? How can *I* modify this setting without using the memory
> CP?

It's a bit in parameter RAM. You can track it down by setting an A-trap
breakpoint on _WriteXPram and changing the setting in the Memory control
panel.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
New sci-fi movie about a failed attempt to surgically modify a human being
to run the first 2-minute mile: "2:00.01 -- a pace oddity."

---------------------------

From: [e-mail] (John Graat)
Subject: Bug in PCloseSkt() ???
Date: 18 Jun 92 14:49:47 GMT
Organization: University of Nijmegen, The Netherlands


Newsgroups: comp.sys.mac.programmer
Subject: Bug in POpenSkt() ???
Summary: Does the preferred interface function POpenSkt() contain a bug?
Keywords: bug appletalk ddp
Organization: University of Nijmegen, The Netherlands

Hello,

In the little program below a socket is opened and closed, using either
the old or the preferred interface. The problem is that every time the
preferred interface is used to open a socket, the closing of the socket
fails. First, you would expect that PCloseSkt causes the problem, but it
seems not to, since using the old interface to close it goes wrong too.

Any idea of what is going on here?
btw: I use MPW 3.0

/* start of program */

#include <AppleTalk.h>
#include <Types.h>
#include <Stdio.h>
#include <Stdlib.h>
#include <String.h>

#define SYNC    false

void main( int argc, char *argv[] )
{
   MPPParamBlock thePB;
   OSErr theError;
   unsigned short theSocket;
   short aSocket;


   //
   // open appletalk
   //
   if ( theError = MPPOpen(), theError != noErr )
   {
      fprintf( stderr, "Error %d occured during MPPOpen.\n", theError );
      exit( 1 );
   }
   else fprintf( stderr, "AppleTalk opened.\n" );


   //
   // open socket
   //
   if ( strcmp( argv[1], "old" ) == 0 )
   {
      aSocket = 0;
      theError = DDPOpenSocket( &aSocket, NULL );
      theSocket = (unsigned short) (aSocket & 0xFF);
   }
   else if ( strcmp( argv[1], "new" ) == 0 )
   {
      thePB.DDPsocket   = 0;
      thePB.DDPlistener = NULL;
      theError = POpenSkt( &thePB, SYNC );
      theSocket = (unsigned short) (((char) thePB.DDPsocket) & 0xFF);
   }
   else
   {
      fprintf( stderr, "usage: %s old|new old|new.\n", argv[0] );
      exit( 1 );
   }

   if ( theError != noErr )
   {
      fprintf( stderr, "Error %d occured while opening socket.\n", theError );
      exit( 1 );
   }
   else fprintf( stderr, "Socket %u opened.\n", (unsigned) theSocket );


   //
   // close socket
   //
   if ( strcmp( argv[2], "old" ) == 0 )
   {
      aSocket = (short) theSocket & 0xFF;
      theError = DDPCloseSocket( aSocket );
   }
   else if ( strcmp( argv[2], "new" ) == 0 )
   {
      thePB.DDPsocket = (char) (theSocket & 0xFF);
      theError = PCloseSkt( &thePB, SYNC );
   }
   else
   {
      fprintf( stderr, "usage: %s old|new old|new.\n", argv[0] );
      exit( 1 );
   }

   if ( theError != noErr )
   {
      fprintf( stderr, "Error %d occured while closing socket.\n", theError );
      exit( 1 );
   }
   else fprintf( stderr, "Socket closed.\n" );


   //
   // exit
   //
   fprintf( stderr, "Done: %s %s %s.\n", argv[0], argv[1], argv[2] );
   exit( 0 );

}// SocketTest //


# test 1: using the old interface
SocketTest old old
AppleTalk opened.
Socket 250 opened.
Socket closed.
Done: SocketTest old old.

# test 2: using the old interface to open the socket and the preferred
# interface to close it
SocketTest old new
AppleTalk opened.
Socket 250 opened.
Socket closed.
Done: SocketTest old new.

# test 3: using the preferred interface to open and the old one to close the
# socket
SocketTest new old
AppleTalk opened.
Socket 250 opened.
Error -91 occured while closing socket.

# test 4: using the preferred interface to both open and close the
# socket
SocketTest new new
AppleTalk opened.
Socket 250 opened.
Error -91 occured while closing socket.

Although test 3 shows that closing the socket produces an error, it is
likely that the socket is closed anyway, since test 4 returns socket 250
again.
I don't get it.

Greetings,

John Graat.
Faculty of Mathematics and Computer Science
University of Nijmegen
The Netherlands

+++++++++++++++++++++++++++

From: [e-mail] (Kevin Stinson)
Date: Thu, 18 Jun 1992 18:29:47 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (John Graat) writes:
>
>
> Newsgroups: comp.sys.mac.programmer
> Subject: Bug in POpenSkt() ???
> Summary: Does the preferred interface function POpenSkt() contain a bug?
> Keywords: bug appletalk ddp
> Organization: University of Nijmegen, The Netherlands
>
> Hello,
>
> In the little program below a socket is opened and closed, using either
> the old or the preferred interface. The problem is that every time the
> preferred interface is used to open a socket, the closing of the socket
> fails. First, you would expect that PCloseSkt causes the problem, but it
> seems not to, since using the old interface to close it goes wrong too.
>
> Any idea of what is going on here?
> btw: I use MPW 3.0
>
> [ Program deleted ]
>
>
> Although test 3 shows that closing the socket produces an error, it is
> likely that the socket is closed anyway, since test 4 returns socket 250
> again.
> I don't get it.
>
> Greetings,
>
> John Graat.
> Faculty of Mathematics and Computer Science
> University of Nijmegen
> The Netherlands

Note that the close fails only if you had opened the socket with the preferred interface,
not the old interface. The problem is that you are not providing a socket listener on
the DDPOpen with the preferred interface.

On the current Mac implementation of AppleTalk, a socket is considered open only if it
has a nonzero socket listener associated with it. Since you opened the socket with a
null listener, the DDP close failed because DDP thinks that the socket was not really
open.

The old interface provided a default socket listener (so DDPRead would work) so this is
not a problem with the old interface.

So, you can:

Use the old interface to open the socket and then use the preferred interface for the
other operations.

 or

Use the preferred interface to open the socket but provide a socket listener (see IM vol
2 for info on how to write a socket listener). If you don't care about receiving any
packets, you can use a "dump the packet" listener:

    SocketListener:
          MOVEQ    #0, D3                ; no buffer to hold the data
                                        JMP            2(A4)                 ; call ReadRest to dump the data

Kevin Stinson
AppleShare Engineer
Apple Computer, Inc.

    - I said it, not Apple!

---------------------------

From: [e-mail] (John Graat)
Subject: How to find the "blessed folder"?
Date: 18 Jun 92 15:24:12 GMT
Organization: University of Nijmegen, The Netherlands

Hello,

Can someone tell me how I can find the "blessed folder"? I known that
Technical Note 67 refers to Inside Macintosh V6, but the FindFolder
function they are referring to, is only available under system 7, but
I'm using system 6.0.7.
I need to know this because I want to put a preference file in this
folder.

Thanks in advance,

John Graat
Faculty of Mathematics and Computer Science
University of Nijmegen
The Netherlands

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 18 Jun 92 16:55:47 GMT
Organization: Kalamazoo College

[e-mail] (John Graat) writes:
>
>Can someone tell me how I can find the "blessed folder"? I known that
>Technical Note 67 refers to Inside Macintosh V6, but the FindFolder
>function they are referring to, is only available under system 7, but
>I'm using system 6.0.7.

I'm told by a reliable source that Think C (and, therefore, probably
Think Pascal as well) provides glue for FindFolder that works under
system 6.  I don't know if MPW does this.  I also don't know if the glue
respects the "create folder if it doesn't exist" bit, but I doubt it.

In any event, the easiest way is to use SysEnvirons, documented in the
opening pages of IM V.

>I need to know this because I want to put a preference file in this
>folder.

If you'd prefer, under system 6, to look for and/or create a folder
called "Preferences," or whatever the Dutch equivalent is, you can find
sample code in my CPrefsFile's "findFolder" method.  It's available from
ftp.brown.edu in /pub/tcl/classes.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Set the cursor on suspend and resume events.

+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Organization: UM Home for the Terminally Analytical
Date: Thu, 18 Jun 1992 18:29:30 GMT

In article <[e-mail]>, [e-mail] (John Graat) writes:

> Can someone tell me how I can find the "blessed folder"? I known that
> Technical Note 67 refers to Inside Macintosh V6, but the FindFolder
> function they are referring to, is only available under system 7, but
> I'm using system 6.0.7.

I'm very careful that when they REMOVE information from a technical
note I stash the old version.  The old versions of tn67 tell you how
to do it manually (i.e. for system 6).

But this one is easy!  They tell you how to SET the blessed folder,
just stuff the appropriate directory ID into ioVFnderInfo[1] and
write it back with the PBGetVInfo/PBSetVInfo suite.  Well, that's
where it lives, and the old version of the tech note simply suggests
that you get it from the ioVFnderInfo returned by a PBGetVInfo on
the startup volume.

What they don't talk about is, for multiple volume systems, how to
figure out which V to get Info of, especially in the case that the
user has run the Set Startup Device control panel and changed the
startup volume but has not yet rebooted.

I'd be inclined to maybe do a GetFCBInfo on the system file's
resource file number and look at ioFCBParID, or else use the one
in the Environs record as Jamie suggests...


+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 19 Jun 92 07:51:14 GMT
Organization: Apple DTS

In article <[e-mail]> [e-mail] (Charles B. Cranston) writes:
>I'm very careful that when they REMOVE information from a technical
>note I stash the old version.  The old versions of tn67 tell you how
>to do it manually (i.e. for system 6).

Oh, c'mon.  If a note has been revised, it's for a good reason.
Following outdated advice is a bad idea.  We're not trying to
pretend that System 6 doesn't exist.

If you're using MPW or Think C or Pascal, call FindFolder.  As Jamie
mentioned, glue is provided that makes it work under System 6 as
well as under System 7.  Unless you explicitly disable or bypass
the compiler glue, that's all you need to do; no call to Gestalt
is necessary to see if FindFolder is present.

If you _have_ disabled the glue, and you wish to find the system
folder under System 6, the simplest solution is to get the WDRefNum
returned by SysEnvirons and convert it to a proper vRefNum/dirID pair
with GetWDInfo.

Incidentally, the FindFolder glue will return the System folder's dirID
when asked for the Preferences folder under System 6.  Go ahead and
store your preferences in whatever directory FindFolder suggests.

Grobbins        [e-mail]


---------------------------

From: [e-mail] (Mark Hayes)
Subject: Yucky "QuickTime Pict" thing in my dialog
Date: 19 Jun 92 14:44:36 GMT
Organization: Boston University, Boston, MA, USA

My "about this program..." dialog contains a nice little PICT which,
unfortunately, only displays when I run with QuickTime. When I run
without it, instead of my cool picture I get an ugly B&W thing
that says "QuickTime Pict" in its place. I certainly didn't
deliberately try to take advantage of any QuickTimeyness here,
so can anyone tell me what's going on?

+++++++++++++++++++++++++++

From: [e-mail] (Frank Giraffe)
Organization: Whole Earth 'Lectronic Link
Date: Fri, 19 Jun 1992 16:07:19 GMT


Sounds like the PICT was originally made with Quicktime compression turned
on. Where did you get the PICT from?
- -Frank
- --
>Frank Giraffe- [e-mail] - {apple,pacbell,ucbvax}!well!fgiraffe
>As the noose of narco-militarism tightens 'round our necks, we worry about
>  burning flags and pee in jars at work to keep our jobs.  -- Jello Biafra

+++++++++++++++++++++++++++

From: [e-mail] (Mark Hayes)
Date: 19 Jun 92 18:46:27 GMT
Organization: Boston University, Boston, MA, USA

In article <[e-mail]> [e-mail] (Frank Giraffe) writes:
>Sounds like the PICT was originally made with Quicktime compression turned
>on. Where did you get the PICT from?

The PICT resource was created by opening a PICT data file with
GifConverter, selecting the entire image, doing a "copy",
then pasting the contents of the clipboard into a resource file.
QuickTime was installed at the time. So apparently the system
(or could it be GifConverter?) handles such cut-and-paste
operations differently when QT is present.

(Sorry I didn't mention this in my original posting. For those who
missed it, doing the above gave me a PICT resource that wouldn't
display without QuickTime installed, giving an ugly "QuickTime PICT"
picture in its place.)

---------------------------

Subject: to Null terminated [SUMMARY] and thanks
From: [e-mail]
Date: 16 Jun 92 23:06:28 CST
Organization: University of Kansas Academic Computing Serces


Thanks for all who sent info (over 10 people).  Combining several
peoples suggestions I came up with the following:

procedure PascalToZero (var s: Str255; var length: longInt);
  var
   s1: Str255;
 begin
  s1 := s;
  length := integer(s1[0]);
  BlockMove(@s1[1], @s, length);
  s[length] := Chr(0);
 end;

The length variable is so that I can convert the string back more easily.
It is crazy I convert the Pascal strings to C strings and then the first
thing the XCMD does is call me back to reconvert them to Pascal strings.
Now that I know the order that the callbacks come in I'm not sure but I
could send empty strings and then send the correct Pascal strings in the
callback.  I still don't have the XCMD figured out exactly (I can call
one of a pair that I don't need but the one that I need I can't call correctly
yet.

Thanks to all who responded though.  i appreciate you help.


---------------------------

From: [e-mail] (Mel Walker)
Subject: How does PrintMonitor do it?
Date: 17 Jun 92 17:14:02 GMT
Organization: Novell, Inc. - Walnut Creek

I was wondering how PrintMonitor knows when I have spooled a job, so that it
can start up? I assume that the Finder launches it. I was wondering if I
could write a program that could get launched like PrintMonitor does. Is
there a general mechanism that exists for this? I'm specifically thinking
of System 7, but how to do it under System 6 would also be interesting.
- --
+ Mel Walker
+ [e-mail]
+ mwalker.PRV_QM_ENG@wc_smtp_knet.wc.novell.com
+ Macintosh Testing Team, Novell

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Date: 17 Jun 92 18:30:48 GMT
Organization: University of Illinois at Urbana

[e-mail] (Mel Walker) writes:

>I was wondering how PrintMonitor knows when I have spooled a job, so that it
>can start up? I assume that the Finder launches it. I was wondering if I
>could write a program that could get launched like PrintMonitor does. Is
>there a general mechanism that exists for this? I'm specifically thinking
>of System 7, but how to do it under System 6 would also be interesting.

Under System 6, a small background-only application (Backgrounder)
constantly checked the spool folder and launched PrintMonitor when
necessary. Under System 7, there appears to be no separate application
running, so I take it that the OS itself takes care of it. In any
event, this is very easy to do under System 7 if you want to do it
yourself:

1. Write your application.

2. Write a small application that is background only, file type 'appe'.
It should be in the Extensions folder and it will make the call to
_LaunchApplication when some event occurs. (NB: The Desktop Manager
routines in System 7 are a good way to find the application to launch
it.)

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

---------------------------

End of C.S.M.P. Digest
**********************